Skip to content

iio: adc: Add initial driver support for MAX14001/MAX14002 #2848

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 6 commits into
base: rpi-6.6.y_GSOC_2025_MAX14001
Choose a base branch
from

Conversation

MarileneGarcia
Copy link

@MarileneGarcia MarileneGarcia commented Jul 13, 2025

The MAX14001/MAX14002 are configurable, isolated 10-bit ADCs for multi-range binary inputs.

Datasheet:
Link: https://www.analog.com/media/en/technical-documentation/data-sheets/MAX14001-MAX14002.pdf

PR Description

Basic IIO ADC max14001 driver features:

  • Definitions for register addresses and useful constants (if any).
  • Definitions for the IIO channels.
  • Device state struct.
  • read_raw and write_raw function implementations (just a mock for now).
  • iio_info struct populated with a reference to the read_raw and write_raw functions.
  • Probe function to initialize and make basic setup for the device.
  • SPI and device tree MODULE_DEVICE_TABLEs
  • Device tree overlay for Raspberry Pi 5
  • Basic max14001 SPI read and write functions

PR Type

  • New feature (a change that adds new functionality)

PR Checklist

  • I have conducted a self-review of my own code changes
  • I tested it on the Raspberry Pi, but without the max14001 board, I couldn't fully validate it yet.
  • Evidence of some basic features working
Screenshot from 2025-07-13 20-02-34

The MAX14001/MAX14002 are configurable, isolated 10-bit ADCs for
multi-range binary inputs.

Datasheet:
Link: https://www.analog.com/media/en/technical-documentation/data-sheets/MAX14001-MAX14002.pdf

Signed-off-by: Marilene A Garcia <marilene.agarcia@gmail.com>
@MarileneGarcia MarileneGarcia force-pushed the rpi-6.6.y_GSOC_2025_MAX14001 branch from 8e965dc to 0ecd86d Compare July 13, 2025 23:58
Copy link
Contributor

@machschmitt machschmitt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @MarileneGarcia , a few comments about this initial driver version.
Note that, aside from the comments above, there are still some improvements that need to be made to make this driver usable (e.g. read ADC sample data, provide scale to convert output codes to mV). Those features shall be implemented next. Though, overall, this looks good to me as an initial driver version.

Copy link

@jonathanns jonathanns left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a few more notes.

@MarileneGarcia
Copy link
Author

Hi @MarileneGarcia , a few comments about this initial driver version. Note that, aside from the comments above, there are still some improvements that need to be made to make this driver usable (e.g. read ADC sample data, provide scale to convert output codes to mV). Those features shall be implemented next. Though, overall, this looks good to me as an initial driver version.

Ok, thank you for the comments! I think I have address them. I will start working in the other needed features, like the read ADC sample data and provide scale to convert output codes to mV.

@MarileneGarcia MarileneGarcia force-pushed the rpi-6.6.y_GSOC_2025_MAX14001 branch from d29debd to f6eaef5 Compare July 20, 2025 15:37
@MarileneGarcia
Copy link
Author

Just a few more notes.

Ok, thank you for the comments! I think I have address them. The ones related to the write_raw I am going to check in the next steps.

- Update the ovelay file to reflect the evaluation board name
- Add Vddl and Vrefin regulators to the overlay file
- Update the log print methods
- Remove unnecessary code
- Improve code style
- Add chip_info struct
- Add max14001_spi_write_single_reg method, which enables and
  disables the write register when writing data to another register

Signed-off-by: Marilene A Garcia <marilene.agarcia@gmail.com>
@MarileneGarcia MarileneGarcia force-pushed the rpi-6.6.y_GSOC_2025_MAX14001 branch from f6eaef5 to b451319 Compare July 20, 2025 15:50
Copy link
Contributor

@machschmitt machschmitt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me.

A few more comments.
The regulator thing can be done on a different PR (we might need to rebase or create another GSoC branch if updating to kernel 6.12).

Keep up the good work.

- Add regulators
- Provide scale to convert opcodes to mV
- Read ADC sample data

Signed-off-by: Marilene A Garcia <marilene.agarcia@gmail.com>
@MarileneGarcia MarileneGarcia force-pushed the rpi-6.6.y_GSOC_2025_MAX14001 branch from d83610c to 42f812b Compare July 24, 2025 11:01
…CALE return value

- Remove max14001_get_scale method
- Fix typo

Signed-off-by: Marilene A Garcia <marilene.agarcia@gmail.com>
Copy link
Contributor

@machschmitt machschmitt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @MarileneGarcia , the updates to MAX14001 driver look mostly good to me. I would merge the PR, but I think it will actually be easier to do the suggested changes before merging this rather than doing them later. So, I'll wait until the last adjustments are done to merge this PR.

@MarileneGarcia
Copy link
Author

Hi @MarileneGarcia , the updates to MAX14001 driver look mostly good to me. I would merge the PR, but I think it will actually be easier to do the suggested changes before merging this rather than doing them later. So, I'll wait until the last adjustments are done to merge this PR.

Hello @machschmitt. Sure, I have done the requested changes, thank you!
I also submitted the initial version of the device tree documentation. And a new method to set the value of the verification registers, which should be done every time the device powers up.

- Fix memory validation fault related to verification registers
values at power-on-reset (POR)
- Add device tree documentation for MAX14001/MAX14002
- Move regulators initialization logic to probe function

Signed-off-by: Marilene A Garcia <marilene.agarcia@gmail.com>
@MarileneGarcia MarileneGarcia force-pushed the rpi-6.6.y_GSOC_2025_MAX14001 branch from 81f5aa9 to 6c5e260 Compare July 27, 2025 23:39
- The read and write functions were tested on actual hardware and
both worked fine
- Fix the overlay to be correctly read by the driver

Signed-off-by: Marilene A Garcia <marilene.agarcia@gmail.com>
@MarileneGarcia MarileneGarcia force-pushed the rpi-6.6.y_GSOC_2025_MAX14001 branch from 3bd2356 to 295b094 Compare August 7, 2025 01:06
Copy link
Contributor

@machschmitt machschmitt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @MarileneGarcia , a few comments about the dt-bindings and new code. I'll have a closer look at MAX14001 data sheets to provide a more accurate review this weekend.

Comment on lines +29 to +33
'#address-cells':
const: 1

'#size-cells':
const: 0
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are not needed when the ADC nodes don't have child nodes (i.e. when the ADC channels are not described in device tree). Drop those

-  '#address-cells':
-    const: 1
-
-  '#size-cells':
-    const: 0


Datasheet can be found here
https://www.analog.com/media/en/technical-documentation/data-sheets/MAX14001-MAX14002.pdf

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reference to spi-peripheral-props can be made here

$ref: /schemas/spi/spi-peripheral-props.yaml#

Comment on lines +62 to +63
allOf:
- $ref: /schemas/spi/spi-peripheral-props.yaml#
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can then be declared right after the main dt-binding description, as mentioned above.


static int max14001_spi_read(struct max14001_state *st, u16 reg, int *val)
{
u16 rx, tx = 0;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIO subsystem maintainer's preference is to avoid multiple variable declaration with assignment like that.
Instead, split the declarations

-	u16 rx, tx = 0;
+	u16 tx = 0;
+	u16 rx;

Comment on lines +113 to +125
struct spi_transfer xfer[] = {
{
.tx_buf = &tx,
.len = sizeof(tx),
.bits_per_word = 16,
.cs_change = 1,
},
{
.rx_buf = &rx,
.len = sizeof(rx),
.bits_per_word = 16,
},
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We normally declare local variables at the beginning of functions. Please, declare xfer close to int ret.

tx |= FIELD_PREP(MAX14001_MASK_DATA, val);
tx = bitrev16(tx);

struct spi_transfer xfer[] = {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here, declare xfer nearby int ret. By the way, IIRC, tx_buf and rx_buf will be declared in the state struct so setting xfer buffers will be set differently.

Comment on lines +308 to +312
if (ret < 0) {
st->vref_mv = 1250000 / 1000;
} else {
st->vref_mv = ret / 1000;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nitpicking: preferred style is to suppress brackets when both if and else blocks have only one line each

	if (ret < 0)
		st->vref_mv = 1250000 / 1000;
	else
		st->vref_mv = ret / 1000;

goto erro_condition;

/* Write verification register value */
val_write_reg = (u16)val_read_reg;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is a bit odd. I guess declaring u16 val_read_reg lead to build warnings due to max14001_spi_read() taking an int as third argument? I'll have a closer look at MAX14001 and MAX14001PMB data sheets this weekend.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants